We are aware that we don't add so much content to Factorio these days. The reason we always state is that we are focusing on polishing and finishing the game. There are a lot of little things and details (some call it quality of life improvements), that don't look that awesome when reviewed one by one, but once they accumulate together they should make a big difference in the game experience. I'm going to talk about some of them now, but don't be afraid that we won't add anything new in the 0.16, as the work on the artillery train has already started and it is probably going to be epic :).
Removing RTL language translations Wheybags I'm sorry to say that we have removed the RTL language translations (Hebrew and Arabic) in 0.17.20. Until this point we've had a half implementation of RTL languages, where the text is simply flipped when we download it from Crowdin. This 'works' for a decent proportion of things, but not nearly 100%. In order to attain the level of polish we want for the 1.0 release, we would need to spend a lot of time implementing proper support for RTL layouts. This just doesn't make sense for us given our current goals, and the proportion of our player base which uses these languages (less than 0.1%). We decided that instead of completely gutting the translations, we could leave them in for those who enjoy them, but not to offer them in the GUI as defaults. The languages will remain up on Crowdin, and the locale files will still be present in game, but there will be no option in the in-game language options dialog to choose them. If you want to use an RTL language, you will have to manually edit your config file to set your locale. Detailed instructions are available on our forum. What this also means, is that we won't be investigating any bug reports about RTL issues.
Lua Mod GUI additions Rseding Mod GUIs have been an interesting part of Factorio modding since I started working at Wube. They allow scenarios and mods to add GUIs that look and feel like the base game. When someone new to Factorio modding is introduced to how they function, they almost always have the same questions: Why is mod GUI part of the game state? Why do mod GUIs need to be deterministic? How can I edit the base game GUIs? And then comes the explanation: The actual widgets are not part of the game state and are not deterministic. The part that mods have access to however is. In an environment where mods have to operate deterministically, if a mod is allowed to read some data that data must be deterministic. In that simple bit of logic; if a mod can read the checked state of a checkbox then that checked state needs to be deterministic. If the mod didn't have access to read that state it would need to store the last-known state and update it every time it got the changed event. Try to imagine that: every single mod implementing their own system for remembering last-known-state about GUIs they're using. Instead of leaving that entire mess to mod developers we decided long ago that we would manage that "last-known-state" for them. The basic data about what a given mod wanted to show on screen is recorded so mods can read and change it as they want and not need to be concerned with constantly updating it every time some changed event happens. Additionally it means that the game can use that "last known state" to restore what the player sees if they save, quit, and load the game. That still leaves the last question: "How can I edit the base game GUIs?". Using the above example it's much easier to explain that: as a mod - you can't. The base game GUIs are not implemented using this same system - they're just pure collections of widgets. None of the "last known state" is saved anywhere and it's all lost when saving, quitting, and loading. However, that leaves a divide: we need to implement each widget type through the "CustomGui" system in order for mods to be able to use them. With this latest release I finally figured out a way to do tabbed panes since they're special in how they work compared to everything else. Additionally I figured out a semi-friendly way for mods to put things directly on the screen in a way that the player can drag them around - instead of being limited to some fixed area (left, top, center, etc). Another system which I've been thinking about for quite some time is some way for mods to position GUI elements relative to base game GUIs. For example: a mod wants to add a pane which shows on the left of the character inventory GUI. Currently it's not possible - the base game GUI isn't readable by mods so they can't do anything with it. My idea is some system where a mod can say "I want to add this GUI, and I want it to be shown relative to the character GUI on the left side" and then any time the character GUI is shown it would also show the mod GUI. There are some critical parts to this new system. It needs to: Be easy to expand (either automatically works with all new base game GUIs or works with minimal effort). Not break with simple refactoring. Not cause other programmers trouble by existing. Not prevent base game GUIs from working how they need to work. So far none of it seems impossible. I don't know when I'll have it working, but I'm looking forward to what mods will do with it.
Hello, It's Earendel back for another electric adventure. You got your first look at Fulgora in FFF-398. (If you haven't read that already please read that first.) Now let's take a look at the new planet's mechanics.
GUI progress update (kovarex) This is a continuation of the last status report from FFF-269. As it might not be a surprise, the biggest bottleneck of the 0.17 release is the GUI. I like to believe, that we have learned a lot from the pitfalls of the collaborative creative process of GUI. This is the typical way we were redesigning the GUI: Two to three people started discussing what could be cool to change in the particular GUI. Some people randomly joined and left the ongoing discussion. Arguments to discard certain ideas have to be repeated over and over. Then the discussion is ended because of something. A week later people start talking again, most of them forgot most of the stuff, or were discussing it with different people, so they assume some details of the changes to be understood by everyone, while they aren't. They come to an agreement how it should be done. They have a random discussion about it a week later and figure out, they had completely different ideas about how it should be done, they just didn't articulate them precisely. Both are kind of angry to have to reopen and re-negotiate the subject again. Someone starts to implement the GUI, but half-way through it is uncovered, that there was another layer of misunderstanding when specifying how should the work be done, and we need to go to step 1 again and repeat. Since many GUIs are thought and worked on in parallel, these situations overlapped and amplified the problems of mixing things up in our heads about what we agreed on in which GUI. Luckily, we eventually figured out, that it can't be done like this, and since there is a lot of work in the GUI, we need to make a process. It goes like this: First, there is some general discussion about the GUI, all team members can share their ideas. kovarex + Twinsen sit alone in the office, and discuss for some time (can be hours), all the pros and cons of how things should be done, and make some agreement. Twinsen writes a detailed UX document about the GUI containing the structure, and more importantly the behaviour, in a detailed manner. Twinsen + kovarex discuss the UX document and propose changes until they agree on the final version. Albert + Aleš take the UX document and create a UI mockup based on it. kovarex + Twinsen + Albert agree on the UI mockup or propose changes. Someone is assigned to implement the GUI based on the UX document and UI mockup kovarex reviews that the implementation is correct and points out some inconsistencies that he can see. Part of this step is making sure, that we share as many GUI styles and code as possible across different GUIs. kovarex + Albert have a final look on the implementation and fix final details until they both agree that the screen is fully finished. Having the UX documents/UI mockups always available proved to be a huge time saver. Not only it helps us to solve the communication problems, we also don't have to remember and re-articulate decisions from some time ago as we can just open the document and see what we agreed on and instantly continue where we left off. A good part of this strict pipeline is that we now have better knowledge of the state of the work progress. These are the GUI screens that we hope to deliver for 0.17: .header_cell { text-align:center; font-weight: bold; } .finished { text-align:center; font-weight: bold; } .not_finished { text-align:center; font-weight: bold; } .finished_gui_table { border-spacing: 10px; } .finished_gui_table td { border: 1px; border-style:solid; padding: 5px; } General UX UX draft UX review UI mockup UI review Implementation draft Implementation review Final review Load map Save map Graphics settings Control settings Sound settings Interface settings Other settings Map generator Technology GUI Technology tooltip Recipe/item/entity tooltip Action bar Shortcut bar Train GUI Manage/Install mods Main screen chat Recipe explorer Character screen Menu structure New game Help overlay Chat icon selector Blueprint library You can see, that there is still a lot of to do, but the work tends to accelerate as more and more of the GUI layouts/tilesets/standards are being finalized and reused. The conclusion is that 0.17 experimental in January is possible, but it might be February as well :).
Hello, it is starting to be quite hot here and summer just started. We started to play games during Fridays (at least part of the day), and today we played Don't Starve together which is kind of addictive to be honest, so I really had to force myself to stop and give you some Factorio updates.
Good afternoon everyone, We have commited to releasing the 0.11.0 on 31st of October 2014. That is next Friday. If all goes well, this will be our Halloween present to the community. But there is a busy week ahead of us:) Apart from regular pre-release craziness, doing significant refactorings the day before or fixing bugs at the last minute, there will be more. On Wednesday we have scheduled moving to our new office and on Friday morning (yes that is the release day) we will be giving a presentation at a local university about the project. We gave the same presentation about a year ago when it was not exactly clear whether / how long will we be able to continue working on Factorio. That has definitely changed for better, especially considering we are moving out of "our garage" (our apartment used as a working place), looking for people to work with us and doing other sorts of longer term commitments.
Hello, We have had quite a peaceful week here in the office. Last night we went out for a burger and a beer as a last meal with Ernestas before he flies back home for another few months. It was also quite nostalgic, as we went to a place that we used to go to frequently near our old office, and the staff still remembered us.
Hello there, the 17th of January brings you the 17th edition of the Friday Facts. Recently, even without our active participation the game has been doing quite well. There are plenty of new videos on the youtube and the forum has also been buzzing with activity. One of our fans put it as follows: "Factorio is going places". Well, we certainly hope he is right :). Anyway let's get down to business. The past week has been spent mostly by work on the new functionality for the 0.9. The blueprints and the oil industry. Both of these are quite large tasks so to finish them completely does take a lot of time. Though the core functionality for both is finished and we are now sort of tweaking the details. I have experimented a bit with some new simple pipe vs. assembler setups and it was quite refreshing and fun. We are really curious how this turns out. The oil industry will result in quite a few new recipes and while we are at it we might go and rebalance the recipes overall a bit. There are things we know for sure should be fixed (for instance the green science pack being too cheap and close to the red one) and there are things we want to experiment with a little bit (like introducing a more complex intermediate products - small engine, navigation system, etc.). We haven't mentioned our new trailer for a while. The thing is that we struggled for long to find someone who would be able to compose the music for the video. We even mentioned that in one of the past Friday Facts. After that post we actually got contacted by a player who bought the game and was following its development news. His name is Daniel James Taylor and he is an awesome (now we know that :)) composer from the United Kingdom. Check out his website if you are interested in more details / his music samples. We agreed on the cooperation and he went and composed a great piece of music fitting our new trailer very well. We are now discussing with Daniel further cooperation regarding the sound effects and ambient music for the game. With the music finished, the biggest bulk of the work for the trailer has been done. The last step is to integrate the new graphics (terrain, doo-dads, etc.) into the trailer and polish it to perfection :) This will most probably happen after the 0.9, but we are getting there. Since the "job advertisement" worked so well last time for the music, we have another one :). It is very apparent to anyone opening the game that the items, gui icons, technology pictures, etc. are a mess. So we are looking for a graphic designer to help us out here. Albert's todo list is long enough already and this job is a lot of work. We would prefer someone from the Czech Republic or the vicinity (for easier communication), but the music experience has proved that a quality cooperation can be done based solely on electronic communication as well. Let's see, maybe we will get lucky twice :) Albert has been "in the oil industry state" for a while. We found out that the current pipes are not fitting the art direction very well. Therefore we decided to take a step back and redo the pipes before anything else. The pipes are the base for the other machines so it certainly needs to be done. It does slow the things now a bit, but as the wise man once said: "If you want to run fast, you need to tie your laces well. Or go barefoot." So below is a composition preview of the new pipes and storage tanks that will be used for holding large amounts of fluids. If you feel you have something to say there is a post for that on our forum.